📝 docs(e10): GitHub addressing & representation model (E10-S00) - #85
Conversation
Executes ADR-0021 items 5-8 unamended, on paper, before the port signature freezes. Answers all four REQ-E10-S00 questions and names the conformance case that will prove each. Q1 fork-head addressing (P0): the governed subject moves to MR-relative FileAtBase/FileAtHead; FileAtRef survives for ref-addressed decision inputs. Verified against the tree, not transcribed: exactly two call sites migrate (run.go:270,:274) and six must not - and three of ADR-0021's anchors have drifted, including the D-130 who-may-approve registry read (provider_host.go:292, not :275). Q2 capability predicates: two kinds - probed (endpoint + field + comparison) or contract-proven (a constant licensed by a NAMED conformance case; no case means unknown). GitLab probes 3 of 11 honestly, 1 by heuristic, hardcodes 1 and implicitly assumes 7. eligible-approval-evidence is reachable as `full` on GitHub via codeowners (improving on ADR-0021's prediction), while the aggregate route satisfies nothing. protected-pipeline-source is unknown on BOTH forges - GitLab's strings.Contains(ci_config_path, "@") is a heuristic, not a predicate - which is OQ-33. Q3 record surface (P0): ADR-0021 item 8 option (ii) confirmed. No schema change; git diff schemas/ == 0 holds. Comma-joining gaps into pins.capabilityGap is not a loophole (the allOf forbids the field whenever mergeResultDigest is pinned), so there is no gap-selection rule to invent. The audit-trail cost is pre-existing: aggregate.Result.CapabilityGaps already never reaches the record. Q4 status-to-sentinel: forge.ErrUnauthorized lifts to the port at S02; a GitHub 404 is absence only inside a repo the token can read; a 404 on protection/ruleset reads without permissions.admin is unknown, never absent. Extends the AUD2-S02/REL-03 discrimination into the adapter that mints the sentinel. Design story - no Go, no schema, no catalog row (S01 owns catalog.yaml). Refs: D-155, OQ-33, ADR-0021 items 5-8
…iew fixes)
Independent review of E10-S00 returned REQUEST CHANGES. Fixes F1-F11.
F1 (P1): Q2 row 9 declared GitHub eligible-approval-evidence
`supported{full}` on three conjuncts that establish a CODEOWNERS file
exists, but none of which decides what `full` DENOTES - that the
adapter-computed eligible set EQUALS the forge's. That property has no
forge-readable predicate, exactly the situation row 11 handled correctly;
two identical gaps had opposite treatments. It also contradicted the named
spec input: forge-dossier-github.md section 2 grades the "which typed
principal" property `partial`. Demoted to `unknown` and filed as OQ-34.
The CODEOWNERS route stays legitimate - ADR-0017 section 3 names it - so
the objection is section 3's OTHER clause, "typed eligible principals":
an over-permissive matcher would put an ineligible principal into
ev.Eligibility and approvalSatisfies would record the obligation
satisfied, harm needing no arming. Consequence stated up front: with rows
9 and 11 both unknown, v1 GitHub comments and does not gate.
F8: that CONFIRMS ADR-0021's unknown-forever prediction (whose stated
reason was dossier section 2 step (b)) rather than refining it. D-155
reframed.
F2: the anchor drift was misattributed. `246` appears nowhere in
ADR-0021; `provider_host.go:246 refFilePort` is E10-S02's own DoD at
spec.md:257 - fixed there. ADR-0021's genuine drifts are two.
F3: the twelve minted case IDs had no enforcement path. Written into
S01/S07/S14's DoD in the epic spec.
F4: `record-schema-unchanged-under-multi-gap` could not fail - run.go:394
already validates every record. Replaced with a byte-identical
capabilityGap case plus a positive control. Also corrected the
loophole-closure claim: run.go:368 sets the gap unconditionally, so
mergeResultDigest is null in 100% of runs and the schema's forbid-clause
is latent until S03/S07.
F6: OQ-33 now quotes ADR-0015 section 4 and carries its same-repo route
(branch protection over .github/workflows/**, largely forge-readable) as
a third candidate; "no readable analogue at all" was overstated.
F5: refs/pull/N/head is ADR-0021 item 5, not dossier C13 (which names
refs/pull/N/MERGE). F7: row 1's GitHub C constant now names its case.
F9: gitlab.go:484 is the 200 branch. F10: the REL-03 gate is
provider_host.go:299. F11: unresolvable-ref diagnostic wording noted.
Refs: D-155, OQ-33, OQ-34, ADR-0021 items 5-8, ADR-0017 3, ADR-0015 4
|
Parking this PR — it is blocked on a repo-wide CI break, not on this diff.
That path is inside the Go toolchain’s own source tree. This PR changes zero Go bytes (six Markdown files), so it cannot be the cause. Evidence:
The fix (bump the golangci-lint pin, and/or replace Leaving this open — it should merge unchanged once the toolchain fix lands on |
Review recordThis PR's review happened outside GitHub, so Two independent review rounds, a different reviewer each round. Round 1 — REQUEST CHANGES. One P1: a capability was graded Round 2 — APPROVE, no P0/P1. The lane fixed all five findings and chose the fail-closed remedy for the P1: the capability is now graded Follow-ups recorded, none blocking: R-1 through R-4, plus R-8, are carried into E10-S01 / E10-S06. Check stateThe last This PR carries a maintainer-LGTM governance marker ( |
# Conflicts: # CHANGELOG.md # docs/decisions/decisions.md # docs/planning/open-questions.md
…ANCE marker (D-161)
Maintainer LGTM — granted, and recorded where it is visible
GitHub's How it was brought up to date — merge-down, not rebaseThe head was 2 ahead / 24 behind with three genuine conflicts. Force-push is forbidden All three conflicts were pure append-adjacency and resolved as ordered unions, then verified
The earlier red Scope of this approvalCovers E10-S00 only — docs/spec-only, zero Go, zero schema bytes. Its one review P1 was fixed It is not a blanket waiver: the same marker still guards E10-S02/S04, E11-S02/S04/S06/S07, |
E10-S00 — GitHub addressing & representation model (D-155)
Opening story of the E10 GitHub-forge epic. Establishes the addressing and
representation model the rest of the epic is specified against, and records the
decision as D-155.
What lands
docs/planning/github-addressing-model.md(new, ~525 lines) — the addressing &representation model: how GitHub refs, files, and approval evidence are addressed
and what each capability claim denotes.
docs/decisions/decisions.md— D-155.docs/planning/open-questions.md— OQ-33, OQ-34 filed.openspec/specs/p5-e10-github-forge/spec.md— DoD tightening (the twelve mintedconformance case ids now have an enforcement path written into S01/S07/S14).
openspec/specs/backlog.md,CHANGELOG.md— bookkeeping.Scope
Docs/spec only: zero Go bytes and zero schema bytes changed. Six files, all
Markdown.
Review
Independent review returned REQUEST CHANGES; fixes F1–F11 landed in one fix round,
after which a fresh independent reviewer returned APPROVE with no P0/P1.
The headline fix (F1, P1): row 9 of the Q2 capability table declared GitHub
eligible-approval-evidence
supported{full}on three conjuncts that only establishthat a CODEOWNERS file exists — none of which decides what
fulldenotes, namelythat the adapter-computed eligible set equals the forge's. That property has no
forge-readable predicate, which is exactly the situation row 11 already handled
correctly; two identical gaps had opposite treatments. It also contradicted the named
spec input (
forge-dossier-github.md§2 grades the propertypartial). Demoted tounknownand filed as OQ-34. Stated consequence, up front: with rows 9 and 11both
unknown, v1 GitHub comments and does not gate.Gates
task check(full matrix) andtask changelog-verifygreen on the rebased head.